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ABSTRACT 


In distributed warfare, warfighters operate in remote and 
austere environments with limited support from outside. In 
such situations, each team has to take care of its own 
safety and security. For operations that last over several 
days, even the most highly trained teams are vulnerable to 


fatigue, leading to a loss of focus during long periods of 





boring activities such as night watch. This can lead to 





mission failure and loss of life. We have developed a 





mobile-phone based system to help with the team’s safety by 


providing real-time situational awareness to the team of its 








surroundings. We have built a sensor grid around the team by 
networking several mobile phones using Bluetooth and using 
their built-in components such as accelerometers to capture 


seismic signals and microphone to capture sound in the area. 





When the grid is breached by a human, animal or machine, the 





individual phones capture signals generated by the 
intruders’ movements. These signals are then compiled and 


analyzed to calculate the position of the intruder and alert 





the team about its presence. In implementing this system, 





our goals were to minimize the additional weight to 





warfighter’s gear, run the system on as low power as 


possible, and to make it easy to install and use the system. 
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ye INTRODUCTION 


Small unit operations are often fast-paced and 


resource-constrained, and can often end up in situations 





where the safety of the unit as a whole rests on the 
shoulders of a watchful team member. For example, Army 


Special Forces, Navy Special Warfare, and Marine Corps 





Special Operations often deploy four-man teams deep in enemy 


territory for extended periods of time. Likewise, soldiers 











could be tasked to operate beyond the immediate protection 
of their unit, acting as an Observation or Listening Post 


where the team could be as small as two individuals. Fatigue 





may inevitably degrade the team’s situational awareness. In 





such situations, the team risks ambush by the enemy, leading 
to loss of life or property. Such situations are also common 


in distributed warfighting where small units conduct 





operations in remote, austere environments where security is 


completely organic. The demand for technology-enhanced 
Situational awareness is warranted for both the 
unconventional and conventional levels. 





It would be helpful for the unit to be equipped with a 
lightweight, low-power surveillance capability that could 
raise an alert to the imminent danger in the vicinity. Such 
an alert could be raised as soon as a suspicious entity is 
detected within the range of the surveillance system. From a 
practical point of view, such a capability should be 


implemented without introducing significant additional 





Portions of this work have been previously submitted for publication 
in the SENSIAC and SPIE proceedings. See (Singh 2010, Young 2010). 
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weight, should use as little power as possible, and should 





be quick and easy to install and operate. 


We hav developed a system using current Smartphone 





technology to provide this lightweight and low-power sensor 





network. Modern Smartphone use a series of accelerometers to 





detect the movement and orientation of a phone. The most 
common uses of this information have been to flip screens 


from vertical to horizontal orientation and, in gaming 





applications, to simulate activities like driving a car or 





flying a plane. We have tested the sensitivity and accuracy 


of this accelerometer data. The accelerometer can be sampled 





over a hundred times a second; displaying micro changes in 











the gravitational pull on the device. These micro changes 





represent small vibrations in the phone. When affixed to the 





ground, the vibrations caused by footsteps and vehicles 


register as these micro changes in the accelerometer data. 





In addition, all phones are equipped with microphones for 
making phone calls. Smartphone can be programmed to 
interpret the sound received in decibels. Sound signals can 
also be sampled at over a hundred times a second. Sound can 
be another detection device for our sensor network. By 
combining the two, we increase the accuracy of intruder 


detection. 


A. OBJECTIVES 


Our primary objective in this research area is to 





determin th accuracy of Smartphone accelerometers and 





microphones and their abilities to detect the presence of 


movement. Our secondary objective is to determine if the 





Bluetooth networks are reliable enough to create an ad hoc 





network and transfer alerts to a human sentry. This work 
2 





will show the usefulness of this type of application. Our 
objective is not to endorse any particular type of 
Smartphone. It is to show that any Smartphone with good 
accelerometer and microphone installed has the capabilities 
to be a sensor, and an application could be added to it with 


little to no cost. 


B. SMARTPHONE APPLICATIONS 


The use of advanced Smartphone functionality requires 
the programming of applications to interface with operating 


system and hardware. Our applications focus mainly on the 





accelerometer and microphone. Using Objective-C and the 


IPhone SDK we have developed a sentry application and a 








base-station application to create alerts and transfer them 


to friendly lines. 


alee The Sentry Application 


The sentry application is loaded on the device that is 





placed forward of friendly lines. The application provides 


the following features. 





a. Capture and analysis of the accelerometer and 


microphone data to make the determination as to whether 





there is movement in the vicinity. The device will have the 





option to give an alert siren or to create a silent alarm. 


lon Ad hoc networking via Bluetooth. Currently 
Smartphone do not have the built-in ability to act as Wi-Fi 





hotspots. Therefore, Bluetooth is necessary for our 








networking. The system is designed to be used where ther 


will be no other coverage. The sentry application will 


communicate with the master device to transfer alarms 
silently from the sentry application to the main 


application. 


il Carrier > 11:54 AM 
Enter File Name 





write to file 





Connect | 





Test Message 








Figure 1. Sentry Application 


Figure 1 is a screenshot of the sentry application. It 





currently has the following functionality: 





e Field to name the file where the data is stored 





e Write button to execute write data to file 











e Connect button to initiate the Bluetooth 
connection to the base station 
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e Text field where a simple Bluetooth chat function 


has been implemented. 


2. Base Station Application 


The base station application is kept inside friendly 





lines and communicates with the sentry devices and provides 
the user with the following features: 

a. The user is able to choose the number of sentry 
devices to deploy. When the user chooses the number of 
sentries they want to deploy, an active sentry screen is 


displayed that reflects the deployment configuration. The 








display links graphics on the base station to the Bluetooth- 





connected devices, so when an alert is received the 





corresponding graphic lets the user know which device 





registered the alarm. 
b. The base station acts as the server in the ad 


hoc Bluetooth network. This allows multiple devices to 





connect to the base station. 
c. The user is able to choose how they wish to be 


alerted on an alarm. They are able to choose an alarm or 





just a visual alert. Different situations warrant a silent 


or auditory alarm, as discussed further in this paper. 





Figure 2 is a screenshot of the current base station 


application. It currently has the following functionality: 





e Buttons to choose up to four nodes to connect to 





e Connect button to initiate the Bluetooth 





connection to the sentry station 





e Text field where a simple Bluetooth chat function 


has been implemented. 


wil Carrier > 12:49 PM 


OneNode TwoNodes 


ThreeNodes FourNodes 





connect 





Figure 2. Base Station 


Cc. SMARTPHONE REQUIRED CAPABILITIES 


For the Smartphone to be able to act as a sensor in the 
manner we propose, it must provide the following 


capabilities for data collection: 





Thr accelerometer values: X, Y, and Z-axis 


Sampling: 100 samples per second 
Alert: Playback auditory alarm 
Data Transfer: Bluetooth capability to 





connect to server device 


Sound Recording: microphone that can 
convert signal to Db 


D. CHAPTER OUTLINE DESCRIPTION 


Chapter I gave a brief introduction to the motivations 
and usefulness of Smartphone sensors. Smartphone type 


devices are already being deployed, and we believe their 








capabilities are being underutilized. This chapter also 
discussed the primary objective of this work, a description 


of the applications and the system requirements of devices. 





Our approach is to use a minimal amount of gear, providing 
the users with added functionality, without added weight to 


carry. 


Chapter II provides a description of the IPhone, which 
we used in this project, and how we accessed and filtered 


the accelerometer data. The processed accelerometer data was 











used to detect footsteps. 


Chapter III describes how we accessed the microphone on 





the IPhone and stored the data. It shows how the raw data, 





when graphed, shows audio events as definite spikes in the 





decibel level. The chapter also describes how footfalls and 





digging event appear at regular and predictable intervals. 


Chapter IV gives a description of the experiments that 
were performed. The methodology is described and the results 


are shown in graph form. The experiments performed ranged 








from simple tabletop taps to digging holes at varying 
distances. The chapter continues on to describe some of the 
future tests that need to be carried out as this project 
moves forward. It concludes with the authors’ conclusions on 


the validity and results of the experiments. 


Chapter V is our vision of the employment of the 
sensor. The Marine Corps standard operating procedure is 
used in conjunction with the abilities of the sensor to 
provide some ideas of where and in what situations the 
phones should be employed. This ranges from offensive 


ambushes to a defensive warning grid. 





Chapter VI is a summary of the thesis with my 


conclusions about the project. It also provides guidelines 





for the future of this project. It describes this author’s 


ideas for what needs to be completed before this project can 








be presented real world applications. 


II. ACCELEROMETER AND FILTERING 


This chapter is an overview of the Apple IPhone 3GS’s 





accelerometer. We discuss the specifications of the device 
so as to give a frame of reference for other smartphones 


that have similar or better accelerometers. We also discuss 





the coding involved with reading and interpreting the data 


from the accelerometer. The chapter also shows a_ sample 





graph of the data collected and finishes with an explanation 





of how signals are interpreted as human footsteps vice 


random seismic events. 


In order to use the Apple IPhone 3GS in our research, 
we used unlocked versions of the phone to facilitate data 
transfer during the testing phases. The IPhone uses the 
LIS302DL accelerometer, which has dynamically selectable 


full scales of + 2g/+t 8g, and is capable of measuring 





accelerations with an output data rate of 100 Hz or 400 Hz. 





In testing it, we noted that at 100 HZ we were getting, on 
average, 98 readings per second. Sampling at higher rates 
than 100 Hz may be capable with the LIS302DL but the ability 


to track, process, and write the received data will cause 











the IPhone to drop readings. The ability to detect footsteps 





does not require more than 100 Hz. 


Our current implementation has not fully put all data 








processing on the device. We have found it necessary to 
store the data and move it off the device for processing. 
Currently, 100 values per second are written to a text file 


and this text file is transferred off the device to allow us 





to levy the power of programs like Matlab and Octave to 


process the data. We are currently using a combination of a 





4 order Butterworth 


low pass filter on the phone and a 
filter off the device, which has been giving us_ some 


distinct events that can be used to raise an alert. 














Filtering techniques can continue to be improved in order to 


make the device more and more sensitive. This filtering will 








then be written on the phone so the phone can filter the 
data as it comes in and make instantaneous decisions on 


alerts. 


A. IPHONE ACCELEROMETER ACCESS 


To understand the capabilities of the IPhone, it is 
necessary to review how the IPhone uses Objective C and 


COCOA to access the phones hardware. Objective C imports 





frameworks in similar fashion to Java and other object- 


oriented languages. Where Java has Application Programming 











Interfaces (APT) to interface with different hardware 
devices, Objective C has "delegates". In IPhone, the 
delegate we are interested in is the 
UIAccelerometerDelegate. Tie defines a single method, 





didAccelerate, that allows us to receive acceleration- 


related data from the system (Apple Inc, 2008). This 








functionality first became available in IPhone OS 2.0. 








The UlAccelerometerDelegat starts a secondary thread 





that fires the didAccelerate method at a rate that is set by 








the user. For our purposes, we fired the method 100 times 








per second. While in the didAccelerat method, it is 


possible to receive a float value that gives the number of 








Gs (multiples of gravity) that the accelerometer is 





experiencing on each of the three axes. Below is an example 
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of a didAccelerate method that demonstrates how one would 





read accelerometer values and output them to a predefined 


set of labels. 





-—(void) accelerometer: (UIAccelerometer*) accelerometer 


didAccelerate: (UIAcceleration *)acceleration 





labelX.text = [NSString stringWithFormat:@"S@%sf", 
@"X: ", acceleration.x]; 

labelY.text = [NSString stringWithFormat:@"S@%f", 
@"y: ", acceleration.y]; 

labelZ.text = [NSString stringWithFormat:@"S@%f", 
@"Z: ", acceleration.z];} 














B. ACCELEROMETER FILTERING 





The accelerometer in the IPhone produces much seismic 


noise. This is the biggest problem that we have been faced 





with in our research. Even when sitting on a perfectly still 
surface, there is a baseline of noise received by the phone, 
which has a tendency to mask usable data. We have 
implemented different types of filters with varying success. 
Figure 3 shows a plotting of activity during a static 
period. There was no movement of any kind during this 25- 


second period. It is clear that there is some activity 





occurring to give the accelerometer these constantly 


changing values. 
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Figure 3. Noise Example 


4** order 


By using a combination of low-pass 
Butterworth filters and integrating audio detection, we have 
seen clear footstep signals rise above the noise, which we 


Gan use to generate an alert signal. Further filtering wil 





cause too many false negatives for the alarm to be useful at 


any distance of more than a few feet. 


1. Onboard Filtering 


The current smoothing technique used in the 


didAccelerate method is a standard low-pass filter, taken 








from the IPhone Developers site. It removes the baseline 
gravity and only measures the instantaneous changes in 


acceleration. This takes all three values and sets their 





baseline to 0. 
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#define kFilteringFactor 0.1 


accelX = acceleration.x - ( (acceleration.x * 





kFilteringFactor) + (accelX* (1.0-kFilteringFactor)) ); 








This filtering allows us to combine the thr values 








making vibrations felt on two different axes to compound 





their effect. The values are combined by taking the square 


root of the sum of the squares of the three axes. When the 








three axes are combined this way, any motion registered on 








any of the thr axes will affect the result. 


2. Off Device Filtering 


The data that has been transferred off the device for 


use in more powerful analytical languages is stored in the 





form of a text file and contains a timestamp, accelerations 


in x, y, and z, and the sound decibel value. We have used 





Octave and Matlab to perform analysis on the data. Below is 
a sampling of how the data was stored on the text file. The 


time stamp shows the date and time down to the millisecond. 


06/04/2010. 102 30¢50:26AM x2, 0.036224 sys, =0.996170 
,Z:, —0.108673 ,comb:, 0.812215 ,sound:, -53.422604 


06/04/2010: LO: 30250:29AM: sor, O, 018112 yyi, S02996170 
,Zi, —0.108673 ,comb:, 0.730586 ,sound:, -54.087948 


06/047 2010" 0s 305 50.30AM xs, O20OUSTIZ py, =0.996L 70 
,Z:, —0.108673 ,comb:, 0.657528 ,sound:, -54.087948 








Once we have the data transferred off the device, w 








process it using Octave. The data is read into a matrix and 
run through a 4‘ order Butterworth Filter with user-defined 


cutoff frequencies. The data is then plotted against time 
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and observed visually. Figure 4 shows the results of 


filtered data of a series of taps while the phone rested on 


a tabletop. 








Oo 5 10 15 
Time ( seconds) 


Figure 4. Example Seismic Plot 





a. Kurtosis 


20 


Kurtosis is the statistical measure of the 
peakedness of the signature (Succi, Clapp, Gampert, & Prado, 
2001). The formula below is how these values are calculated. 


A group of samples is taken spanning a period of time. 


> (@,- uy 
XG -#y 
We 1 : 


Where x; is the current sample and wp is the computed mean 


over N samples; 
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qth ond 


It is determined from the and moments of 
the signal peak. Kurtosis can be described as how spiky the 
amplitudes are in the data; it is taken of a sample of time 
and compared to a baseline. 


If the kurtosis is significantly higher, then an 





alert can be raised. Instead of doing extensive baseline 
experiments and storing baseline information we propose to 
compare the kurtosis of the current period with a period 5 
to 10 seconds prior. This allows us to have a running 
average kurtosis, and if it spikes, we know to raise an 


alarm. In Figure 5, a simple visual analysis of the data 





shows that in sample 1 the kurtosis is clearly lower than in 





sample 2. This would demonstrate alert conditions on the 


sensor. 
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Figure 5. Kurtosis Example 


Cc. SUMMARY 


This chapter has discussed the hardware and software 


that the IPhone 3GS uses to recognize movements in the 


15 





phone. The accelerometer measures the values on three axis 


and we are able to detect very fine vibrations in these 





readings. We also showed what the acceleration values look 
like when graphed against time. The chapter finished by 


discussing how spikes in the acceleration data can be 





interpreted as a human presence. 





The next chapter discusses how we used the microphone 
equipped for voice calls to detect human presences from the 


noise made by their footsteps. 
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III. AUDIO PROCESSING 


A. BACKGROUND 


Analysis of vibration data can be enhanced by adding 
the analysis of sound passing through the air and recorded 
by traditional microphones. Microphones pick up less of the 
natural frequencies of the ground than vibration sensors, 
and generally record clear impulses for footsteps and other 
percussive sounds of interest. Most of these signals show a 


broad band of frequencies so frequency analysis is not 





especially valuable. Time-domain analysis of the vibration 
Signal can be used to find audio peaks. Microphones do pick 
up more spurious signals than vibration sensors due to many 
common forms of background noise such as motors. However, a 
vibration peak that coincides with an audio peak tends to be 
more likely to be meaningful than one that does not, and 
thus audio provides confirmatory data for vibration 


analysis. 


Sound processing operates on a similar fashion as the 
accelerometer data. The IPhone microphone has a frequency 
response from 20Hz to 20,000Hz. It supports a wide variety 


of audio formats. Our tests stored the data in a .wav 





format. We are currently testing the benefit of using 
different audio formats. The data is plotted in a similar 


way as the seismic data. The data is the strength of the 





Signal plotted against time in milliseconds. The signal 





strength in decibels operates in a range from -60 (quiet) to 


O (loud). Below is a sample graph of an audio signal. 
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Figure 6. Example Audio Plot 
B. IPHONE AUDIO RECORDING 
Our Objective C project implemented the 





AVAudioRecorderDelegate to access the microphone (Apple 








Inc., 2009). The AVAudioRecorderDelegate implements methods 
to handle the recording such as the recording process and 
handling errors. When our program is run, the IPhone starts 
a recording method where several settings are initalized 
such as the sample rate and location of the stored 
recording. To process audio data, we must save the sound 


recording. We need to further test recording lengths to 





determe the maximum amount of time we can record before 


running into memory and hardware errors. We used a standard 
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timer thread that fired a function 100 times per second. It 
was in this method that we wrote the sound values to the 


same text file that the accelerometer data is stored. The 





result is a single text file that includes the three 





accelerometer values and the sound in decibels. We can take 
this file off the IPhone for data processing using stronger 
programs such as Matlab and Octave. When the suitable 
algorithms are found, the sound processing will have to be 


done onboard the IPhone to provide real-time alerts. 


Cc. AUDIO PROCESSING 


Positive peaks of the energy detected by an audio 


sensor generally signal interesting phenomena. To find 





them, we adapted techniques from our research on audio 








tracking (Rowe, Reed, & Flores, 2010). We first subtract the 





Signal from its mean value over th ner recording 


interval to eliminate low-frequency components. We then set 





to zero all portions below a threshold set as a multiple of 








the standard deviation of the signal; 1.5 times the standard 








deviation worked well in our experiments. The reason for 





ignoring negative portions of the signal is that footsteps 


and other percussive sounds generally create a momentary 





increase of sound pressure stronger than the subsequent 


negative peak, and thus is easier to detect. 


We then look for peaks in the remaining signal. At a 





sampling rate of 100 hertz, typical footstep peaks will 
cover 3-20 samples and we did not find a need for further 
smoothing. We currently search for values that are the 


maximum in a centered window of seven samples, and found 





this to be adequate coverage. The time and height of each 


peak found are calculated and stored, as well as _ peak 
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narrowness (ratio of average height before and after 0.045 
seconds to the peak height), and asymmetry (ratio of the 
difference of the heights 0.045 seconds before and after to 
the peak height). 


For footsteps, we exploit the observation in (Sabatier 
& Ekimov, 2008) that normal footsteps of the same walker are 
not less than 0.48 seconds apart and no more than 0.80 
seconds apart. We search for sequences of peaks that obey 
this constraint. We explored using the narrowness and 
asymmetry to help with matching, but found they did not help 


much because footsteps from the same pedestrian can vary 





Significantly in shape. 





The best clue to distinguishing footsteps from 





background noise is in their periodicity. Thus, we search 
for groups of two, three, and then four footsteps in 
sequence. Since nearly all clear footsteps will occur at 


least in groups of four, sounds that do not belong to such a 





sequence are unlikely to be footsteps. We rate members of 








sequences by the evenness in time of the peaks in the 
sequence. Sequences of footsteps at a good distance from 


the microphone should also show only a single local maximum 








of the peak heights at the time of closest approach. 
However, nearby footsteps may show two maxima with typical 
sound-recording microphones with a narrow angle of 


sensitivity (directionality), one for the closest approach 





and one for the angle most along the axis of the microphone. 


The IPhone audio microphone is directional, but the 





vibration sensors are not. 


For excavation behavior, we will also see periodic 





peaks of 1 to 10 seconds, but they will be less regular. 
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Peaks should be roughly the same width, so this gives us an 


additional clue. We are also starting to search for the 





human voice as it indicates conversations and is usually a 
negative clue (a clue arguing against concealment and 


suspicious behavior). 


D. SUMMARY 





In this chapter, we have discussed the hardware that is 
used in the IPhone 3GS as it relates to audio reception. We 
explained the packages imported that gave us the ability to 
process audio and showed a graph of the sound values when 
compared to time. The chapter finishes with an explanation 
of how the audio signals can be interpreted to make a 


determination of footsteps versus other auditory events. 


The next chapter brings us to the xperimentation 








phase. There is an overview of the systems design, and we 





discuss some of th xperiments conducted, as well as the 


validity and meaning of their results. 
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IV. SYSTEM ARCHITECTURE AND EXPERIMENTS 


A. BACKGROUND 


The tests described in this section were all used a 





proof of concept to determine whether the accelerometer and 
equipment is sensitive enough to detect the vibrations 
produced by the footsteps of a bypassing human. In the 
diagram below, we can trace the workings of the client 
application from the data received by the phone to the off 
device data processing. The current testing did not use the 


server application. 


Thread hat 
fires every 
millisecond 


Post test 
actions 





Output 





Figure 7. Flow of Control 
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Original experiments were conducted indoors at the 
Naval Postgraduate School Computer Science Lab. The device 
performed well on tabletops and floors. With these promising 
results, the tests were taken outdoors. Our testing to date 
has been on hard packed dirt surfaces; these will give us 
the best seismic wave transfer in an attempt to prove the 


abilities of the phone. We took the testing to the back 





roads of the former Fort Ord. This made sure we were a great 
distance from any possible contamination. The stand that was 
used was constructed from parts bought from the local 


hardware store for less than four dollars. (Figure 8) 





Plastic Bowl 


Steel Rod 


Figure 8. Stand Example 
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Steel Rod 
Figure 9. IPhone Placement 


B. PROCESS 


The Phone was secured to the steel rod inside the 


plastic bowl. The idea is that the seismic vibrations, that 











travel in the top 6”-8” of the soil, will transfer to 





vibrations in the steel rod. The rod will then vibrate the 


phone. The plastic bowl operates in the similar fashion as a 








phonograph horn amplifying the vibrations. We experimented 
with several different orientations of the phone. Our best 


results came when we laid the phone face down and balanced 








on the rod, as seen in Figure 9. We used the following 


procedure. 


1. Dig small hole to get the phone as close to ground 





level as possible, about two to four inches deep. Geophones 





and devices like ours become more effective the closer the 





device is to surface level. 
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2. Place phone in stand and start the application. 
Beginning the application, in our program, begins the 
process of recording seismic and audio values at a rate of 
100 times per second. While the program is running, these 


values are stored in an NSMutableArray. 


3. Begin filming. All experiments were filmed with 








video to have a visual record of the subject’s relation to 
the phone at any given time. This can then be translated 


into actions that are correlated with events in the data. 


4. Tap phone 5 times to create a reference point in 
data to begin test. A large audio and seismic event can be 
linked to an action in the video to create an accurate 


events timeline. 


5. Run test with periods of walking and periods of no 
movement. The periods of no movement were just as important 


as the periods of activity. We used these periods to form 








the baseline of events that we attempted to filter out. 


6. Transfer data to a computer for filtering and 


analysis. We are currently doing this manually using the 





Jailbroken IPhone application called NetATalk. 





We also found it useful to run two sensors in close 


proximity to each other. This allowed us to vary the two 





sensors and look for more results. For example, we found 





that a phone in a horizontal orientation gave better 
results than a phone with a vertical orientation. We were 


also able to use a comparison of two signals to cancel out 





ground noise. If the same spike is noticed at two different 


sensors, it is unlikely that it is a human causing the 
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alert. It is also our goal to eventually use the strength 
of signal from two different sensors to give a more 
accurate location of the event. In Figure 10, we would 


expect to see a stronger event signal on Sensor 1 than 





Sensor 2. By comparing the two signals, we would be able to 
determine that the subject is passing between the two 
sensors but is closer to Sensor 1. We could accurately 


track their direction based on this data. 


Subjects path 


- 
2 Sensor 1 
Sensor 2 


Figure 10. Dual Sensor Example 


Cc. RESULTS 


In this section, we discuss some tests we conducted and 





show the seismic activity received by each test. Each graph 
will represent the norm of the acceleration (combined X, Y, 


Z accelerometer values) plotted on the Y axis of the graph 





with time in seconds plotted on the X axis. We are looking 





for spikes in the data that show a strong vibration or a 
wider period of a weaker vibration that show other 


activities. 
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Figure 11. Table Top Results 


Figure 11 depicts one of our first tests. The phone was 


laid flat on a table and the table was tapped at a distance 


of 5 feet from the phone. The two sets of five taps are 





clearly visible from second 2 through 3.5 and 4.5 through 6. 
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Figure 12. Trail Example (Seismic) 


Trail Walking 
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Figure 13. Trail Results (Audio) 
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Figure 12 represents a test that occurred on a hard 
packed trail. The sensor was set up to the side of the trail 


and the subject was a 200-pound man wearing boots. He walked 





down the trail passing directly by the sensor around second 





267. There are several peaks in the middle of the time frame 
showing the approach of the subject. The peak at 274 was a 


hammer strike near the sensor to mark the data. 


Figure 13 shows the processed audio of the same test. 


The footsteps are clearly visible. The sound values are 





stored as a running average of the surround second, this is 


why there is a hump in the middle, and it shows the approach 





and retreat of the test subject. 


We also conducted some experiments of our ability to 





detect digging. This would be useful to determine if an 
enemy is attempting to dig under a fence or place an 
Improved Explosive Device (IED). Digging produces a much 


higher seismic signal than simple walking, and a _ phone 





should detect this action at a further distance. We were 





able to see some activity when digging occurred within a few 


meters of the phone but will test larger distances. 
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Figure 14. Digging Results 





Figure 14 is of a seismic test where we performed 
digging with a full-size shovel at a distance of 10 feet. 


The figure shows a 15-second interval where there were 





shovel strikes at 65 and 73 seconds. The graph and data did 
not reveal activity above the noise to the level that we 


could provide an alert. 


A second test was performed, this time we used two 
phones. We placed one phone five feet from the digging site 


and the other ten feet from the dig site. When this data was 





analyzed, I used a much stricter high cut and low cuts on 


the Butterworth filter. I used a value of 45 for the low cut 





and 50 for the high cut. This effectively grouped the data a 


little more and made some peaks much more visible. 
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Figure 17. Second Digging Test (Audio) 





The data shows that there are some significant seismic 
events occurring. It is correlated by the audio. In order to 


compare the data, we overlaid it and lined the charts up 





using significant events and the results can be seen in 


Figure 18. It is clear that several of the seismic events 





lined up between the two charts. There is more activity in 


the 5-foot chart, which is to be expected. Where these data 





points line up, it clearly points to the effectiveness of 





the sensor to detect events that were caused by the digging. 
The audio spikes at the expected times show the sound caused 


by these events. 
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Figure 18. Digging Overlay 


D. FUTURE TESTS 


Future work will explore the effect of ground types. We 


will obtain baseline seismic data that will be preloaded 





into the application. The user will select the type of 
ground the sensors are placed in and this will change the 
thresholds where we are looking for anomalies. Harder packed 


dirt will likely carry a seismic signal longer, so the 





threshold can be set higher to decrease false positives. A 





sandy area will have very little seismic wave traffic and 


the audio signal will be the main source of alert detection. 
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E. SUMMARY AND CONCLUSIONS 





The tests that we performed covered situations from 
indoors to outdoors and from walking to digging. The seismic 
Signals that our IPhone captured were quite noisy. However, 
there were some promising results. The phone clearly 


recognized footsteps indoors, and an application could give 





alerts in that situation. Outdoor monitoring revealed a 
smaller radius wherein the device would recognize an event. 


We believe there is some noise in the device that is masking 





the footsteps; close passes are recognized but footsteps at 
a further distance disappear in the noise. Additional 
filtering and improved hardware could provide better 


results. 


Chapter V is the author’s views on how these systems 
could be deployed in a small unit setting. It gives diagrams 
and scenarios on where and when to deploy sensors in order 


to maximize the effectiveness of the grid. 
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V. APPLICATIONS 


Our ground sensors have a wide range of uses to the 





warfighter. Consider here some scenarios based on fireteam 


and platoon-level offensive and defensive operations. Our 





current calculations have used six meters as the detection 





radius for any given sensor. Since we are attempting to use 





only Smartphone and no external gear, we have used Bluetooth 





that is built into the device to create an ad hoc network to 








transfer the alerts to the base stations. The IPhone 3GS did 





not provide wireless hotspots on its own, so Wi-Fi was ruled 


out. Another concern we have in our applications is the 








battery life. It would be impractical to place all four 


devices out for the night, since this would drain their 














batteries and leave the unit without their phones 


subsequently. Conversations with representatives from Apple 





Inc. reveal that they are working on this problem. They are 
developing portable chargers, including solar cells, to 


extend the length of batteries to maximize military 





interests in the IPhone. Other Smartphone have replaceabl 





batteries; this would be our suggestion for purchasing 


Smartphone for the U.S. Military. 


A. OFFENSIVE OPERATIONS 


Our system could be used in many different offensive 
operations including ambushes and urban missions. In an 
ambush, the sensor could be placed in the likely avenue of 
approach such as a road or trail. The sensor would operate 
as a trigger to prepare the unit for immediate action. The 
sensor works well at night and for a unit sitting a long 


time in the ambush waiting for the ambush to develop. A 
af 


sensor placed in the avenue of approach would recognize 


movement giving the ambushing unit significant notice. The 





few seconds could mean the difference between a successful 
ambush with coordinated fire or an unsuccessful one where 
the ambush is tripped early or late. The sensor will give an 
accurate location of the enemy as they approach the area. 


Figure 19 shows an example where the enemy is expected to 








come from one direction. Figure 20, where the enemy’s 
location is not known, the phone will pinpoint the direction 


the enemy is coming from. 

















Likely Enemy 
Approach 
Setup Ambush 
Figure 19. Ambush Example w/ Known Avenue of Approach 
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Figure 20. Ambush Example w/o Known Avenue of Approach 











B. DEFENSIVE OPERATIONS 


We now discuss several defensive configurations based 
on standard Marine Corps operating procedures. The standard 
deployment of teams consists of the fireteam consisting of 
four members. The members will keep five to twenty meters 
away from each other to avoid multiple casualties from a 
Single explosion. Fireteams generally consist of a Team 
Leader, an Automatic Rifleman, an Assistant Automatic 
Rifleman, and a Rifleman. The sensors would be deployed 
based on needs of the mission. For instance, Figure 21 shows 


a deployment configuration where the team wants to deploy 





all of their sensors with an auditory alarm. Figure 22 shows 
a situation when friendly lines are known and the team wants 
to maximize the sensor coverage in a given direction. By 


deploying all four sensors for a four-person team, the team 
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is left without a base station; so all alarms will have to 





be auditory. An auditory alarm will alert the enemy to the 
sensor, as well as the friendly team, but it may cause 
confusion among the enemy while alerting the friendly team 


to the direction of the alarm. 





Figure 21. Defensive Example Non-Directional w/ Auditory 
Alarm 





Friendly Lines 


Figure 22. Defensive Example Directional w/ Auditory Alarm 
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If a team is deployed behind enemy lines and is trying 





to maintain stealth, it may be beneficial to deploy sensors 


with a silent alarm. The sensor array will be networked 





back to a base station that is monitored by the team member 


on watch. A tripped alarm will silently give an alert and 





rough direction to the watch giving him an opportunity to 
assess the situation and determine if an attack is imminent 
or can be avoided. This should give the team the few 
seconds of additional warning. Figures 23 and 24 show a 
couple examples of deployment options for such a silent 


array. 





Figure 23. Defensive Example Non-Directional w/ Silent Alarm 
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Friendly Lines 


Figure 24. Defensive Examples Directional w/Silent Alarm 





The Smartphone sensors can also deployed to extend the 
effective range of the unit’s forward listening post. When a 


platoon or company sets up a defensive position, the 





commander is tasked with recognizing likely avenues of 


approach and deploying listening/observation posts The 





listening post is usually a two-man team placed as far as 
safely possible in front of friendly lines. They have a 
radio to call back any activity to the friendly lines. At 
night this post has a limited range. Figure 25 displays a 


Situation where the sensors would be placed ahead of 





friendly lines to increase the effective range of a 





Listening Post. The nightly post is sent ahead to give the 
main line a pair of ears to warn the platoon of approaching 
enemy. Figure 26 shows how the sensors could be placed to 


cover areas that are hidden from a unit’s line of sight. 
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Figure 25. Listening Post Used in Platoon Defense 


@ 
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Friendly Lines 
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base station 
Figure 26. Platoon Defensive Examples 
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Cc. OTHER USES 


The phones have also shown good detection capabilities 
indoors. This shows promise for the device to act as a 
makeshift alarm system when operating in urban terrain. A 


team that takes up a security position inside a building 





could use the phones in a number Of different 





configurations, such as placing a phone on floors to detect 


movement or near entrances. The phone would be limited by 





the radio connection, as Bluetooth does not travel well 





through objects such as walls and floors. 


Tripwires and other external sensors such as motion 


detectors would be a way that a unit could improve the 





accuracy of the device. A tripwire is a small wire attached 
to the end of the phone and a stationary object. In this 
way, touching the tripwire would cause a large spike in the 


seismic signal and would raise an instant alarm. We could 





again use silent or auditory alarms for the same reasons 


discussed above. 


D. SUMMARY 


This chapter discussed some of the author’s ideas on 
the deployment of the device in a field environment. There 
is a wide range of scenarios where a quick and small ground 


sensor could come in use. Offensive situations would allow 





for a trigger point for ambushes while defensive perimeters 








would use it to extend their ears into the dark. There was 
also discussion on other, non-conventional, ways to use the 


sensor. 


The next chapter provides some concluding thoughts and 


areas for future work on this project. 
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VI. CONCLUSIONS AND FUTURE WORK 


A. CONCLUSIONS 


We have discussed the use of a Smartphone as an 
unattended ground sensor. We have discovered that the 


accelerometer inside the device is accurate enough to be 





used for military applications. The microphone is an 





excellent complement to the accelerometer, and a combination 
of both could provide a fairly accurate alert system for 
small unit operations. But the data we obtained in 


experiments contained considerable noise that is produced by 





the phone or accelerometer module inside the phone. This 





noise is the biggest obstacle in the development of a full- 








scale application to generate and pass on alerts to a base 


station. Continued filtering techniques combined with 








further maturing of the Smartphone accelerometer technology 





could provide a cleaner signal and reduce the number of 


false positives and provide an accurate and useful tool. 





The testing we conducted provided good results in 
controlled environments such as a tabletop and an indoor 


concrete floor. Moving the device to an outdoor environment 





added more noise to the signal while reducing the footprint 





Signature, which made seismic footsteps harder to detect. 
However, the microphone on the device provided some very 
promising data that showed the approach and retreat of a 


test subject along with individual footsteps. 





The capabilities of Smartphone are improving at a rapid 
pace. There are already phones in the market with 1GHz 


processor. These phones will eliminate the need to transfer 
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data to another computer for processing. Also, significant 
amount of research is being done on improving battery 


technology, as well as on reducing the power consumption of 





the phones. These would help make applications such as ours 


more practical on phones. 


B. FUTURE WORK 


Processing of vibration and audio data from a device 


should be done on the device for greatest efficiency. Each 





sentry device should make its own assessments on raising an 
alert. In the IPhone, we are using Objective C to write the 


applications; however, the IPhone also ports the C language 











directly. Thus, we are attempting to use Matlab to perform 





calculations and we will use the abilities of Matlab to 








translate to C to perform the same algorithm on the phone. 





The kurtosis readings will take place at a set number of 
seconds to keep the processing down to a level where it will 


not cause lag in the phone. 


The determination of when to raise an alert is key. We 
must run field tests in real environments to assess the 
accuracy of the device. It will require us to make 
determinations on acceptable levels of false positives and 
negatives. As we try to capture more distant alerts, we risk 
getting more false positive alerts caused by ground and 


TPhone noise. 


We hope that as we improve our detection algorithms to 


the point were we could attach strength of alert value to an 





alert received. If we could determine how strong an alert 
is, we could guess how for away from a phone the seismic 


event is occurring. This would be useful as subsequent 
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alerts become higher or lower; then the base station would 
interpret this as a threat moving toward or away from the 


sensor. 


Tests should be done to determine how multiple phones 


could interact with each other to give the base station a 








clearer picture of where an alert is originating. The base 





station may be able to register multiple alerts from 





multiple phones. These alerts would be processed based on 





the strength of the alert and the occurrences of alerts and 








the phone could be taught to determine a most likely 





location using triangulation. 


Another concern with the current devices on the market 





is the length of the battery. The IPhone is especially 


vulnerable to this problem as there is no way to recharge it 





quickly. There are several solutions in the works to correct 








this problem. The Apple Corporation is developing mobile 





solar cells to charge the phone. Similar mobile charging 
devices could make the IPhone viable. However, several other 


phones such as the Motorola Droid have a replaceable 








battery. This would allow the operator to carry multiple 

















batteries that could be replaced when needed. 
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